1. Field of the Invention
The present invention relates to tracking transaction related data within a computerized device in general, and to tracking transaction related data in a multi-tier computerized environment, in particular.
2. Discussion of the Related Art
A complex, multi-tier computerized network environment makes it difficult to keep track of a single transaction as it spans across multiple tiers. A tier can be a software or hardware module that executes an application. An example for such multi-tier computerized environment can be shown in FIG. 1, Multi-tier computerized network environment 100 comprises three tiers—an http server 115 (Tier 1), application server 120 (Tier 2), a storage element, for example a database server 150 (Tier 3). Communication between the tiers is bidirectional. For example, requests are transmitted from one tier to another and data related to the requests is sent back to the requesting tier. HTTP request 110 is received at HTTP server 115 (Tier 1). As a result, HTTP server 115 (Tier 1) transmits two Internet Inter Operable Protocol (IIOP) requests 120, 125 to application server 130 (Tier 2). In other cases, two different requests may be transmitted to two different tiers. Application server 130 receives IIOP request 120 that issues request 135 and IIOP request 125 that issues requests 140 and 145. SQL request 135 is transmitted to database tier 150 (Tier 3) in order to provide data to HOP request 120. After SQL request 135 is satisfied, the data related to the response for the SQL query is transmitted hack to application server 130 (Tier 2). Next, SQL requests 140, 145 are transmitted to database tier 150 (Tier 3) in order to provide data to IIOP request 125. After both requests 120 and 125 are satisfied, data related to IIOP requests 120, 125 is transmitted hack from application server 130 (Tier 2) to HTTP server 115 (Tier 1) so HTTP request 110 can be satisfied. Tier 3 is not capable, according to the computerized environments disclosed in the prior art, to detect the tier that transmitted SQL request 135, Further, Tier 1 is not capable of detecting that the performance of Tier 3 may also be affected by requests 120, 125.
In such an environment, a transaction may start in a HTTP tier, such as a web portal, and then travel across various different legacy systems, servers, databases; packaged and homegrown applications. A transaction is mostly composed of more than one request, transmitted among tiers for receiving data or for transmitting commands, for example a request may transmit a process in command to one tier, which results in a mathematical analysis of data stored within a database tier. Each single transaction is generated by either a person or an automatic computer system sending commands, eventually spanning through more than one physical or logical tier within the application processing the transaction. A single request arriving to the entry point of an application, the web server for example, will generate additional requests in other tiers. Now known systems try to achieve “tree” like view that will represent the flow of a transaction including additional requests generated in order to satisfy the transaction. Such attempts have not been successful.
In present computerized environments, there is currently no efficient manner of tracking the accurate route of a single transaction in a generic manner that combines various configurations and topologies. Current solutions do not provide the ability to track and present an accurate tracking and flow of a single transaction or several transactions. In addition, present solutions do not provide a tool for measuring the overall resource consumption each request requires in a specific tier. Resource consumption can be determined in many measurable attributes, such as time, memory units, bandwidth, amount of data and the like.
One presently available solution offers assigning a unique transaction ID for each new transaction. According to this solution, a processing tier logs the requests and its related parameters, such that these logs are received at a central storage where the route can be detected by correlating the requests according to the unique transaction ID with the said logs. This solution is inadequate and limited because it is limited to systems where all the applications and processing tiers share the same holder, programmer, supplier or another entity that can access the code. However, most currently available computerized environments comprise a plurality of operating systems, communications protocols, databases and the like, making the above solution ineffective. Another approach is to capture a content related to events or requests, such as for example, registers or memory content. According to the suggested solution, one can extract most of the SQL commands handled by the examined database, but cannot extract all the SQL commands because of delay between the time an incoming request arrive to the time of its extraction, since new commands need to be processed before extraction. Hence, the above solution is not up-to-date and does not provide transaction related data in real-time. Further, the delayed data prevents the solution to provide data with sufficient accuracy.
Another approach uses existing APIs exposed by the tiers. For example, a module can request from a Java Virtual Machine (JVM) to be notified every time a request is handled by the JVM. This allows the extraction of every event within the JVM. The above approach is not generic and depends on the specific tier. If the tier modifies its APIs or internal structure, the method will cease to perform and will require adjustments. In addition, the above method cause performance overhead; therefore, it is problematic when used in production environments. The above methods are based on the existence of a unique id in order to reassemble the transaction route. If no such id exists then they have no way to track. Several solutions for tracking transactions and requests parse data between tiers in the application level. The resolution of such data is insufficient and tracking is inaccurate. Further, the time required until data is transmitted to the application level prevents the described solution to provide real time results and to pause or terminate requests and transactions before they are handled in the tiers.                There is therefore a need for a new method and apparatus for tracking transactions in realtime and in an efficient and accurate manner.        